Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make valid::expressions module depend on "validate" feature. #2480

Closed
wants to merge 1 commit into from

Conversation

jimblandy
Copy link
Member

Rather than having #[cfg(feature = "validate")] attributes on almost every definition in src/valid/expressions.rs, move the definitions we need unconditionally out of the module, and just put the whole module under a #[cfg].

Rather than having `#[cfg(feature = "validate")]` attributes on almost
every definition in `src/valid/expressions.rs`, move the definitions we
need unconditionally out of the module, and just put the whole module
under a `#[cfg]`.
@jimblandy jimblandy requested a review from teoxoy September 15, 2023 16:27
@@ -243,6 +243,121 @@ pub enum ValidationError {
Corrupted,
}

#[derive(Clone, Debug, thiserror::Error)]
#[cfg_attr(test, derive(PartialEq))]
pub enum ExpressionError {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have to move this out? Can we make it conditional on the feature flag instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with making it conditional is that that changes the API of the validator. We want turning off "validate" to simply make producing ModuleInfo faster, without changing its API.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example, clients that happen to be checking for particular ExpressionError variants shouldn't break.

Hmm. Maybe it's preferable for any users checking for FunctionError::Expression to get a compilation error if the "validation" feature is off, since that error will never be generated and users shouldn't be thinking it could happen?

API stability and deliberate API instability both seem to have arguments in their favor. Which do you think is more useful?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's natural for feature flags to expose more of the API.

For users that turn on the flag, all enum variants of ValidationError will be present, for those who don't they may or may not be there but I don't think those users would exhaustively match the enum anyway.

@cwfitzgerald
Copy link
Member

Hello, thank you for your PR against Naga!

As part of gfx-rs/wgpu#4231, we have moved development of Naga into the wgpu repository in the Naga subfolder. We have transferred all issues, but we are unable to automatically transfer PRs.

As such, please recreate your PR against the wgpu repository. We apologize for the inconvenience this causes, but will make contributing to both projects more streamlined going forward.

We are leaving PRs open, but once they are transferred, please close the original Naga PR.

@jimblandy
Copy link
Member Author

Since validation is no longer behind a feature, this PR is irrelevant.

@jimblandy jimblandy closed this Jan 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants